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Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 
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GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3 GPP and ETSI identities can be found under 
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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 

Introduction 

The present document is part of a TS-family covering the 3^^ Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication management; as identified below: 

TS 32.150: Integration Reference Point (IRP) Concept and definitions 

TS 32.151: Integration Reference Point (IRP) Information Service (IS) template 

TS 32.152: Integration Reference Point (IRP) Information Service (IS) Unified Modelling Language 

(UML) repertoire 

TS 32.153 Integration Reference Point (IRP) technology specific templates 

TS 32.154 Backward and Forward Compatibility (BFC); Concept and definitions 

TS 32.155 Requirements template 
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Scope 



The present document contains the template to be used for the production of all Integration Reference Point (IRP) 
Information Service (IS) specifications within the 3GPP 32-series. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept 

and definitions". 

[4] 3GPP TS 32.152: "Telecommunication management; Integration Reference Point (IRP) 

Information Service (IS) Unified Modelling Language (UML) repertoire". 

[5] 3GPP TS 32.622: "Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)". 

[6] 3GPP TS 32.1 1 1-2: "Telecommunication management; Fault Management; Part 2: Alarm 

Integration Reference Point (IRP): Information Service". 

[7] 3GPP TS 32.302: "Telecommunication Management; Configuration Management (CM); 

Notification Integration Reference Point (IRP): Information Service (IS)". 

[8] ITU-T Recommendation M.3020 (2009): Management interface specification methodology - 

Annex E Information type definitions - type repertoire. 

[9] 3GPP TS 32.602: "Telecommunication Management; Configuration Management (CM): Basic 

CM IRP: Information Service (IS)". 

[10] 3GPP TS 32.612: "Telecommunication Management; Configuration Management (CM): Bulk CM 

IRP: Information Service (IS)". 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 32.101 [1], 3GPP TS 32.102 [2], 
3GPP TS 32.150 [3] and the following apply: 

IRPAgent: See 3GPP TS 32.150 [3]. 

IRPManager: See 3GPP TS 32.150 [3]. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TS 32.101 [1], 3GPP TS 32.102 [2], 
3GPP TS 32.150 [3] and the following apply: 

IOC Information Object Class 

IRP Integration Reference Point 

IS Information Service 

OMG Object Management Group 

UML Unified Modelling Language (OMG) 



Infornnation Service (IS) tennplate 



The present document contains the templates to be used for the production of all Integration Reference Point (IRP) 
Information Service (IS) specifications within the 3GPP 32-series. 

For the introductory clause 1 (Scope) of all NRM IRP ISs, clause Wl shall be used. 

For the introductory clause 1 (Scope) of all Interface IRP ISs, clause W2 shall be used. 

For the introductory clauses 2 and 3 of all IRP ISs, the text shall be written conforming to the standard 3GPP TS 
template (i.e. not this IRP IS template). 

The other clauses in this template that shall be used in the IS specifications following their introductory clauses are 
numbered starting with "X", which in general should correspond to clause 4 that is the beginning of the main part of the 
TS. However, if there is a need in a specific IS to introduce additional clauses in the body, X may correspond to a 
number higher than 4. 

For a NRM IRP IS, only clause X shall be used. 

For an Interface IRP IS, both clauses X and Y shall be used. 

The IS template uses qualifiers M, O, CM, CO and C. The semantics of these qualifiers are defined in TS 32.150 [3]. 

The IS template uses Information Type as one characteristic to describe IOC attributes and operation/notification 
parameters. The valid Information Type(s) that can be used and their semantics are defined in ITU-T M.3020 Annex E 
[8]. 

Usage of fonts shall be according to the following table. 



ETSI 



3GPP TS 32.151 version 10.1.0 Release 10 



ETSI TS 132 151 VI 0.1.0 (2011-05) 



Item 


Font 


Class names 


Courier New 


Attribute names 


Courier New 


Operation names 


Courier New 


Parameter names 


Courier New 


Assertion names 


Courier New 


Notification names 


Courier New 


Exception names 


Courier New 


State names 


Arial 


IVIatching Information 


Courier New 


Information Type 


Courier New 


Legal Values 


Courier New 


NOTE: These font requirements do not apply to UML diagrams. 
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W1 Scope 



The following quoted text is relevant for all NRM IRP ISs. It shall be copied as the first two paragraphs of the NRM 
IRP IS specification. IRP IS author may add additional paragraph(s) if necessary. 



The present document specifies the «n» (where «n» shall be substituted by the name of the NRM IRP IS 
concerned such as "HNS", "EJJTRAN", "GERAN") network resource information that can be communicated between 
an IRP Agent and one or several IRPManagers for network management purposes. 

This document specifies the semantics and behaviour of information object class attributes and relations visible across 
the reference point in a protocol and technology neutral way. It does not define their syntax and encoding. 



W2 Scope 



The following quoted text is relevant for all Interface IRP ISs. It shall be copied as the first two paragraphs of the 
Interface IRP IS specification. IRP IS author may add additional paragraph(s) if necessary. 



The present document specifies the «n» (where «n» shall be substituted by the name of the Interface IRP IS 
concerned such as 'Alarm', 'Test', ' Entry Point') management operations and notifications that can be communicated 
between an IRP Agent and one or several IRPManagers. 

This document specifies the semantics and behaviour of operations, notifications and their parameters visible across the 
reference point in a protocol and technology neutral way. It does not define their syntax and encoding. 



X Information Object Classes 

This 'X' clause shall be used for NRM IRP ISs. This 'X' clause shall also be used for Interface IRP ISs. 
"X" represents a clause number in the actual Information Service TS. 

X.1 Imported information entities and local labels 

This clause identifies a list of information entities (e.g. information object class, interface, information relationship, 
information attribute) that have been defined in other specifications and that are imported in the present specification. 
All imported entities shall be treated as if it is defined locally in present specification. One usage of import is for 
inheritance purpose. Each element of this list is a pair (label reference, local label). The label reference contains the 
name of the specification where it is defined, the type of the information entity and its name. The local label of imported 
information entities can then be used throughout the specification instead of the label reference. 

This information is provided in a table. An example of such a table is given here below: 



Label reference 


Local label 


3GPP TS 32.622 [5], information object class, Top 


Top 
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X.2 Class diagram 

X.2.1 Attributes and relationships 

This first set of diagrams represents all information object classes defined in this IS with all their relationships and all 
their attributes, including relationships with imported lOCs (if any). These diagrams shall contain information object 
class cardinalities (for associations as well as containment relationships) and may also contain association names and 
role names. These shall be UML compliant class diagrams (see also 3GPP TS 32.152 [4]). 

Characteristics (attributes, relationships) of imported information object classes need not to be repeated in the 
diagrams. Information object classes should be defined using the stereotype «InformationObjectClass». 

X.2.2 Inheritance 

This second set of diagrams represents the inheritance hierarchy of all information object classes defined in this IS. 
These diagrams do not need to contain the complete inheritance hierarchy but shall at least contain the parent 
information object classes of all information object classes defined in the present document. By default, an information 
object class inherits from the information object class "top". These shall be UML compliant class diagrams. 

Characteristics (attributes, relationships) of imported information object classes need not to be repeated in the 
diagrams. Information object classes should be defined using the stereotype «InformationObjectClass». 

NOTE: some inheritance relationships presented in clause X.2.2 can be repeated in clause X.2.1 to enhance 
readability. 
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X.3 Information object class definitions 

Each information object class is defined using the following structure. 

Inherited items (attributes etc.) shall not be shown, as they are defined in the parent lOC(s) and thus valid for all 
subclasses. 

X.3. a InformationObjectClassName 

InformationObjectClassName is the name of the information object class. 

"a" represents a number, starting at 1 and increasing by 1 with each new definition of an IOC. 

X.3.a.1 Definition 

The <definition> subclause is written in natural language. The <definition> subclause refers to the information object 
class itself. The characteristics related to the relationships that the object class can have with other object classes can 't 
be found in the definition. The reader has to refer to relationships definition to find such kind of information. 
Information related to inheritance shall be precised here. 

For NRM IRP ISs, information on traceability back to one or more requirements supported by this IOC should also be 
defined here, in the following form: 



Referenced TS 


Requirement label 


Comment 


3GPP TS 32.xyz [xy] 


REQ-SM-CON-23 


Optional clarification 


3GPP TS 32.xyz [xy] 


REQ-SM-FUN-11 


Optional clarification 



X.3.a.2 Attributes 

The <attributes> subclause presents the list of attributes, which are the manageable properties of the object class. 
Each element is a tuple (attributeName, supportQualifier, readQualifier, writeQualifier): 

The supportQualifier indicates whether the attribute is Mandatory (M), Optional (O), Conditional-Mandatory 
(CM), Conditional-Optional (CO), SS- Conditional (C) or Not supported ( — ). 

The readQualifier indicates whether the attribute shall be readable by the IRPManager. Allowed values are: 
Mandatory (M), Optional (O) and Not supported ( — ). 

The writeQualifier indicates whether the attribute shall be writeable by the IRPManager. Allowed values are: 
Mandatory (M), Optional (O) and Not supported ( — ). 

The semantics of the above used qualifiers are defined in TS 32.150 [3]. 

There is a dependency relationship between the supportQualifier, readQualifier, and writeQualifier. The 
supportQualifier indicates the requirements for the support of the attribute. For any given attribute, regardless of the 
value of the supportQualifier, at least one of the readQualifier or writeQualifier must be 'M". The implication of the 
"O" supportQualifier is that the attribute is optional, however the read and write qualifiers indicate how the optional 
attribute shall be supported, should the optional attribute be supported. 

Private or IRP Agent Internal attributes are per definition not readable by the IRPManager. Their readQualifier is 
hence always " — ". 

Private or IRPAgent Internal attributes are per definition not writable by the IRPManager. Their writeQualifier is 
hence always " — ". 

The readQualifier and writeQualifier of a supported attribute, that is public, may not be both " — ". 

The use of " — " in supportQualifier is reserved for documenting support of attributes defined by an « Archetype » IOC 
Attributes with a supportQualifier of " — " are not implemented by the IOC that is realizing a subset of the attributes 
defined by the « Archetype ». The readQualifier and writeQualifier are of no relevance in this case. However, a not 
supported attribute is neither readable nor writable. For this reason the readQualifier and writeQualifier shall be " — 
for unsupported attributes. 
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For any IOC that uses one or more attributes from an « Archetype », a separate table shall be used to indicate the 
supported attributes. This table is absent if no «Archetype» attributes are supported. For example, if a particular IOC 
has defined attributes (i.e. attributes not defined by an « Archetype ») and encapsulates attributes from two 
« Archetype »s, then the totality of the attributes of said IOC will be contained in three separate tables. 

This information is provided in a table. An example of such a table is given below: 



Attribute name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


ntf Subscript ionid 


M 


M 






Another example, where the support qualifier is "O " is given here below: 



Attribute name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


ntfSubscriptionId 





M 






In this example, the ntfSubscriptionId is an optional attribute. If the implementation chose to support ntfSubscriptionId, 
then the said implementation is required to support read and may support write. 

NOTE: This subclause shall state 'There is no attribute defined. ' when there is no attribute to define. 

X.3.a.3 Attribute constraints 

The Kattribute constraints> subclause presents constraints for the attributes, and one use is to present the predicates 
for conditional qualifiers (CM/CO). 

This information is provided in a table. An example of such a table is given here below: 



Name 


Definition 


pci CM write qualifier 


Centralized PCI assignment (see TS 32.500, ref [15] subclause 
6.1.6) is supported. 


pciList CIVI support qualifier 


Distributed PCI assignment (see TS 32.500, ref [15] subclause 
6.1.6) is supported. 


partOfSectorPower CM 
support qualifier 


The IOC SectorEquipmentFunction is USed. 


attributeX max value 


The value of attributex shall be within the specified value range 
but may never be higher than the value of attributeY. 



NOTE: This subclause shall state 'There is no attribute constraint defined. ' when there is no attribute constraints 
to define. 



X.3.a.4 



Relationships 



The <relationship> subclause presents the list of relationships in which this class in involved. Each element is a 
relationshipName. 

NOTE: This subclause shall state 'There is no attribute constraint defined. ' when there is no relationship 
represented in the class diagram in clause X.2.I. 



X.3.a.5 



State diagram 



The <state diagram> subclause contains state diagrams. A state diagram of an information object class defines 
permitted states of this information object class and the transitions between those states. A state is expressed in terms of 
individual attribute values or a combination of attribute values or involvement in relationships of the information object 
class being defined. This shall be a UML compliant state diagram. 

NOTE: This subclause shall state 'There is no State diagram defined. ' when there is no State diagram defined. 

X.3.a.6 Notifications 

The < Notifications > subclause, for this IOC, presents: 
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a) optionally, a reference to the common notifications defined in subclause X.6 as valid for this IOC, and 

b) optionally, a list of notifications that shall be excluded from the list of common notifications (defined in 
subclause X.6) for this IOC (note: inherited notifications from the parent lOC(s) can not be excluded), and 

c) optionally, a list of notifications applicable to this IOC, and which may or may not be defined in the common 
notifications in subclause X.6. 

The notifications identified in this subclause are notifications that can be emitted across the Itf-N, where the "object 
class" and "object instance" parameters of the notification header (see note 2) of these notifications identifies an 
instance of the IOC defined by the encapsulating subclause (i.e. clause X.3.a). 

The notifications identified in this subclause, may originate from implementation object(s) whose identifier is mapped in 
the implementation, to the object instance identifier used over the Itf-N. Hence the presence of notifications in this 
clause (i.e. clause X.3.a.6) does not imply nor identify those notifications as being originated from an instance of the 
IOC defined by the encapsulating subclause (i.e. clause X.3.a). 

The information related to option c) above is provided in a table. An example of such a table is given below: 



Name 


Qualifier 


Notes 


notifyCMSynchronizationRecommended 





Example notification. 



NOTE I: This subclause shall state 'There is no notification defined for this IOC when there is no notification 
defined for the IOC 

NOTE 2: The notification header is defined in the notification IRP Information service TS 32.302 [7]. 

NOTE 3: The qualifier of a notification, specified in Notification Table, indicates if such notification can carry the 
instance DN in the notification. The qualifier of a notification, specified in an Interface IRP, indicates the 
Interface IRP support level regarding the emission of the subject notification. 

An IRPManager can receive notification-XYZ that carries DN of class-ABC instance if and only if: 

a) The class-ABC Notification Table defines the notification-XYZ and 

b) The class-ABC instance implementation supports this notification-XYZ and 

c) An Interface IRP defines the notification-XYZ and 

d) The Interface IRP implementation supports this notification-XYZ. 
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X.4 Information relationship definitions 

Each information relationship is defined using the following structure. 

Inherited relationships shall not be shown, as they are defined by the parent lOC(s) and thus valid for all subclasses. 

X.4. a InformationRelationshipName (supportQualifier) 

InformationRelationshipName is the name of the information relationship followed by a qualifier indicating whether the 
relationship is Mandatory (M), Optional (O), Conditional-Mandatory (CM), Conditional-Optional (CO), or 
SS-Conditional (C). 

"a" represents a number, starting at 1 and increasing by 1 with each new definition of an information relationship. 

X.4.a.1 Definition 

The <definition> subclause is written in natural language. 

X.4.a.2 Roles 

The <roles> subclause identifies the roles played in the relationship by object classes. Each element is a pair 
(roleName, roleDefinition). 

This information is provided in a table. An example of such a table is given here below: 



Name 


Definition 


isSubscribedBy 


This role represents the one who has subscribed. 



X.4.a.3 Constraints 

The <constraints> subclause contains the list of properties specifying the semantic invariants that must be preserved on 
the relationship. Each element is a pair (propertyName, propertyDefinition). Those properties are always held to be 
true during the lifetime of the relationship and don't need to be repeated in pre or post conditions of operations or 
notifications. 

This information is provided in a table. An example of such a table is given here below: 



Name 



Definition 



inv_notif icationCat 
egoriesAllDistinct 



The notification categories contained in the ntfNotif icationCategorySet attribute of 
Ntf Subscription playing the role theNtfSubscription are all distinct from each other. 
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X.5 



Information attribute definitions 



Each information attribute is defined using the following structure. 

Inherited attributes shall not be shown, as they are defined in the parent lOC(s) and thus valid for all subclasses. 



X.5.1 Definition and Legal Values 

This subclause contains for each attribute being defined its Attribute Name, its Definition written in natural language, 
its Information Type (see [8]) and an optional list of Legal Values supported by the attribute. 

In the case where the Legal Values can be enumerated, each element is a pair (Legal Value Name, Legal Value 
Semantics), unless a Legal Value Semantics applies to several values in which case the Semantics is provided only 
once. When the Legal Values cannot be enumerated, the list of Legal Values is defined by a single definition. 

This information is provided in a table. An example of such a table is given here below: 



Attribute Name 


Definition 


Information Type / Legal Values 


ntfSubscriptionId 


It identifies uniquely a 
subscription 


INTEGER / -- 


ntf SusbcriptionState 


It indicates the activation state 
of a subscription 


ENUMERATED / 

"suspended": the 
subscription is suspended. 
"notSuspended" : the 
subscription is active. 



X.5. 2 Constraints 

The <constraints> subclause indicates whether there are any constraints affecting attributes. Each constraint is defined 
by a pair (property Name, propertyDefinition). PropertyDefinitions are expressed in natural language. 

An example is given here below: 



Name 



Definition 



inv TimerConstraints 



The ntf TimeTickTimer is lower than or equal to ntf TimeTick. 



X.6 Common Notifications 

This <Common Notifications> subclause presents a list of notifications that can be referred to by any IOC defined by 
this IRP specification. These notifications are only applicable to lOCs referring to this subclause in subclause 
'X.3.a.6'. This information is provided in a table. An example of such a table is given below: 



Name 


Qualifier 


Notes 


notifyAttributeValueChange 





Example common notification 


notif yObj ectCreation 





Example 


notif yObj ectDeletion 





Example 



NOTE: This clause does not need to be present when there are no common notifications. 



X.7 System State Model 



Some configurations of information are special or complex enough to justify the usage of a state diagram to clarify 
them. A state diagram in this clause defines permitted states of the system and the transitions between those states. A 
state is expressed in terms of a combination of attribute values constraints or involvement in relationships of one or 
more information object classes. 
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Y Interface Definition 

This 'Y' clause shall be used for Interface IRP ISs. 
"Y" represents a number, immediately following "X". 

Y.1 Class diagram representing interfaces 

Each interface is defined in the diagram. This shall be a UML compliant class diagram (see also 3GPP TS 32.152 [4]). 

Interfaces are defined using a stereotype «Interface». Each interface contains a set of either operations or 
notifications which are mandatory or either a single operation or a single notification which is optional. The support of 
an interface by an information object class is represented by a relationship between the 2 entities with a cardinality 
(1..1) if all the operations or notifications contained in the interface are mandatory, and (0..1) if the operation or 
notification contained in the interface is optional. On the class diagram, each operation and notification in an interface 
shall be qualified as "public" by the addition of a symbol "+ " before each operation and notification. 

Y.2 Generic rules 

The following rules are relevant for all ISs. They shall simply be copied as part of the specification. 

Rule 1: each operation with at least one input parameter supports a pre-condition valid_input_parameter which 
indicates that all input parameters shall be valid with regards to their information type. Additionally, each such 
operation supports an exception operation J'ailed_invalid_input_parameter which is raised when pre-condition 
valid_input_parameter is false. The exception has the same entry and exit state. 

Rule 2: Each operation with at least one optional input parameter supports a set of pre-conditions 
supported_optional_input_parameterjyyy where "yyy" is the name of the optional input parameter and the 
pre-condition indicates that the operation supports the named optional input parameter. Additionally, each such 
operation supports an exception operation J'ailed_unsupported_optional_input_parameterjyyy which is raised when 
(a) the pre-condition supported_optional_input parameter jyyy is false and (b) the named optional input parameter is 
carrying information. The exception has the same entry and exit state. 

Rule 3: each operation shall support a generic exception operation JailedJ.nternal^roblem which is raised when an 
internal problem occurs and that the operation cannot be completed. The exception has the same entry and exit state. 

Y.b InterfaceName Interface (supportQualifier) 

InterfaceName is the name of the interface followed by a qualifier indicating whether the interface is Mandatory (M), 
Optional (O), Conditional-Mandatory (CM), Conditional-Optional (CO), or SS-Conditional (C). 

"b" represents a number, starting at 3 and increasing by 1 with each new definition of an interface. 

Each interface is defined by its name and by a sequence of operations or notifications. 

Interfaces related to operations shall be listed before the interfaces related to notifications. 

If the interface is related to operation(s), the following Y.b. a "Operation OperationName (supportQualifier)" shall be 
applied. 

If the interface is related to notification(s), the next Y.b. a "Notification NotificationName (supportQualifier)" below 
shall be applied. 
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Y.b.a Operation OperationName (supportQualifier) 

OperationName is the name of the operation followed by a qualifier indicating whether the operation is Mandatory 
(M), Optional (O), Conditional-Mandatory (CM), Conditional-Optional (CO), or SS -Conditional (C). 

"a" represents a number, starting at 1 and increasing by 1 with each new definition of an operation. 

Y.b.a.1 Definition 

The <definition> subclause is written in natural language. 

Information on traceability back to one or more requirements supported by this operation should also be defined here, 
in the following form: 



Referenced TS 


Requirement label 


Comment 


3GPP TS 32.xyz [xy] 


REQ-SM-CON-23 


Optional clarification 


3GPP TS 32.xyz [xy] 


REQ-SM-FUN-11 


Optional clarification 



Y.b.a.2 



Input parameters 



List of input parameters of the operation. Each element is a tuple (Parameter Name, Support Qualifier, Information 
Type (see [8] and Note I) and an optional list of Legal Values supported by the parameter. Comment). Legal Values for 
the Support Qualifier are: Mandatory (M), Optional (O), Conditional-Mandatory (CM), Conditional- Optional (CO), or 
SS- Conditional (C). 

This information is provided in a table. An example of such a table is given here below: 



Parameter Name 


Support Qualifier 


Information Type / Legal Values 


Comment — — * 


eventldList 


M 


SET OF INTEGER / -- 


One or more event identifiers 



Note 1 : Information Type qualifies the parameter of Parameter Name. In the case where the Legal Values can be 
enumerated, each element is a pair (Legal Value Name, Legal Value Semantics), unless a Legal Value Semantics 
applies to several values in which case the definition is provided only once. When the Legal Values cannot be 
enumerated, the list of Legal Values is defined by a single definition. 



Y.b.a.3 



Output parameters 



List of output parameters of the operation. Each element is a tuple (Parameter Name, Support Qualifier, Matching 
Information /Information Type (see [8]) (Note I) and an optional list of Legal Values supported by the parameter. 
Comment). Legal Values for the Support Qualifier are: Mandatory (M), Optional (O), Conditional-Mandatory (CM), 
Conditional-Optional (CO), or SS -Conditional (C). 

This information is provided in a table. An example of such a table is given here below: 



Parameter 


Support 


Matching Information / 


Comment 


Name 


Qualifier 


Information Type / Legal Values 




eventTime 


M 


Alarmlnf ormation . alarmRaisedTime 

/ 

GeneralizedTime / -- 


The parameter carries the 






• alarmRaisedTime in case notificationType 








carries notifyNewAlarm, 








• alarmChangedTime in case 








notificationType carries 








notifyChangedAlarm, 








• alarmClearedTime in case 








notificationType carries 








notifyClearedAlarm. 



Note 1 : Information Type qualifies the parameter of Parameter Name. In the case where the Legal Values can be 
enumerated, each element is a pair (Legal Value Name, Legal Value Semantics), unless a Legal Value Semantics 
applies to several values in which case the definition is provided only once. When the Legal Values cannot be 
enumerated, the list of Legal Values is defined by a single definition. 
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This table shall also include a special parameter" status" to indicate the completion status of the operation (success, 
partial success, failure reason etc.). 
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Y.b.a.4 



Pre-condition 



A pre-condition is a collection of assertions joined by AND, OR, and NOT logical operators. The pre-condition must be 
held to be true before the operation is invoked. An example is given here below: 

not ificationCategoriesNot All Subscribed OR 

not ificationCategoriesParameterAbsentAndNot All Subscribed 

Each assertion is defined by a pair (propertyName, property Definition). All assertions constituting the pre-condition 
are provided in a table. An example of such a table is given here below: 



Assertion Name 


Definition 


notif icationCategoriesNotAllSubscribed 


At least one notif icationCategory 
identified in the 

notif icationCategories input 
parameter is supported by iRPAgent and 
is not a member of the 

ntfNotificationCategorySet attribute 
of an Ntf Subscription which is involved 
in a subscription relationship with the 
Ntf Subscriber identified by the 
managerRef erence input parameter. 


notif icationCategoriesParameterAbsentAndNotAllSubscribed 


The notif icationCategories input 
parameter is absent and at least one 
notif icationCategory supported by 
IRPAgent is not a member of the 
ntfNotificationCategorySet attribute 
of an ntf Ssubscription which is 
involved in a subscription relationship with 
the Ntf Subscriber identified by the 
managerRef erence input parameter. 



Y.b.a.5 



Post-condition 



A post-condition is a collection of assertions joined by AND, OR, and NOT logical operators. The post-condition must 
be held to be true after the completion of the operation. When nothing is said in a post-condition regarding an 
information entity, the assumption is that this information entity has not changed compared to what is stated in the 
pre-condition. An example is given here below: 

subscriptionDeleted OR allSubscriptionDeleted 

Each assertion is defined by a pair (propertyName, property Definition). All assertions constituting the post-condition 
are provided in a table. An example of such a table is given here below: 



Assertion Name 


Definition 


subscriptionDeleted 


The ntf Subscription identified by subscriptionid input parameter is no more 
involved in a subscription relationship with the ntf Subscriber identified by the 
managerRef erence input parameter and has been deleted. If this ntf Subscriber has 
no more ntf Subscription, it is deleted as well. 


allSubscriptionDeleted 


In the case subscriptionid input parameter was absent, the ntf Subscriber 
identified by the managerRef erence input parameter is no more involved in any 
subscription relationship and is deleted, the corresponding ntf Subscription have 
been deleted as well. 



Y.b.a.6 



Exceptions 



List of exceptions that can be raised by the operation. Each element is a tuple (exceptionName, condition, 
Returnedlnformation, exitState). 
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Y.b.a.e.c exceptionName 

ExceptionName is the name of an exception. 

"c" represents a number, starting at 1 and increasing by 1 with each new definition of an exception. 

This information is provided in a table. An example of such a table is given here below: 



Exception Name 


Definition 


ope_failed_existing_subscription 


Condition: (notif icationCategoriesNotAllSubscribed OR 

notif icationCategoriesParameterAbsentAndNotAllSubscribed) 

not verified. 

Returned information: output parameter status is set to 

OperationFailedExistingSubscription. 

Exit state: Entry State. 



Each notification is defined using the following structure. 

Y.b.a.7 Constraints 

The < constraints> subclause presents constraints for the operation or its parameters. 

NOTE: This subclause does not need to be present when there are no constraints to define. 
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Y.b.a Notification Notif icationName (supportQualifier) 

NotificationName is the name of the notification followed by a qualifier indicating whether the notification is 
Mandatory (M), Optional (O), Conditional-Mandatory (CM), Conditional-Optional (CO) or SS- Conditional (C). 

"a" represents a number, starting at 1 and increasing by 1 with each new definition of a notification. 



Y.b.a.1 



Definition 



The <definition> subclause is written in natural language. 

Information on traceability back to one or more requirements supported by this notification should also be defined 
here, in the following form: 



Referenced TS 


Requirement label 


Comment 


3GPP TS 32.xyz [xy] 


REQ-SM-CON-23 


Optional clarification 


3GPP TS 32.xyz [xy] 


REQ-SM-FUN-11 


Optional clarification 



Y.b.a.2 



Input parameters 



List of input parameters of the notification. Each element is a tuple (Parameter Name, Qualifiers, Matching Information 
/Information Type (see [8]) (Note I) and an optional list of Legal Values supported by the parameter. Comment). 

The column "Qualifiers" contains the two qualifiers. Support Qualifier and Filtering Qualifier, separated by a comma. 
The Support Qualifier indicates whether the attribute is Mandatory (M), Optional (O), Conditional-Mandatory (CM), 
Conditional-Optional (CO), or SS -Conditional (C). The Filtering Qualifier indicates whether the parameter of the 
notification can be filtered or not. Values are Yes (Y) or No (N). 

This information is provided in a table. An example of such a table is given here below: 



Parameter Name 


Qualifiers 


Matching Information / 
Information Type / Legal Values 


Comment 


managerRef erence 


M,Y 


ntf Subscriber . ntf ManagerRef e 
rence / STRING / -- 


It specifies the reference 
of IRPIVIanager to which 
notifications shall be sent. 


alarmType 


M,Y 


Alarmlnf ormation . eventType 
/ ENUMERATED / 
"Communications Alarm" : a 
communication error alarm. 
"Processing Error Alarm": a 
processing error alarm. 
"Environmental Alarm" : an 
environmental violation 
alarm. 

"Quality Of Service Alarm" : 
a quality of service 
violation alarm. 
"Equipment Alarm" : an alarm 
related to equipment 
malfunction. 





Note 1 : Information Type qualifies the parameter of Parameter Name. In the case where the Legal Values can be 
enumerated, each element is a pair (Legal Value Name, Legal Value Semantics), unless a Legal Value Semantics 
applies to several values in which case the definition is provided only once. When the Legal Values cannot be 
enumerated, the list of Legal Values is defined by a single definition. 



Y.b.a.3 



Triggering event 



The triggering event for the notification to be sent is the transition from the information state defined by the "from 
state " subclause to the information state defined by the "to state " subclause. 
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Y.b.a.3.1 From state 

This subclause is a collection of assertions joined by AND, OR, and NOT logical operators. An example is given here 
below: 

a larmMa tched AND alarmln forma t i onNo tCleared 

Each assertion is defined by a pair (propertyName, property Definition). All assertions constituting the state 'from 
state" are provided in a table. An example of such a table is given here below: 



I Assertion Name 


Definition 


alarmMatched 


The matching-criteria-attributes of the newly generated network alarm has values that are 
identical (matches) with ones in one Alarminf ormation in AlarmList.. 


alarmlnformationNot 
Cleared 


The perceivedSeverity of the newly generated network alarm is not cleared. 



Y.b.a.3.2 To state 

This subclause is a collection of assertions joined by AND, OR and NOT logical operators. When nothing is said in a 
to-state regarding an information entity, the assumption is that this information entity has not changed compared to 
what is stated in the from state. An example is given here below: 

resetAcknowledgementlnformation AND perceivedSeverityUpdated 

Each assertion is defined by a pair (propertyName, propertyDefinition). All assertions constituting the state "to state " 
are provided in a table. An example of such a table is given here below: 



Assertion Name 


Definition 


reset Acknowledgemen 
t Information 


The matched Alarminf ormation identified in inv_alarm Matched in pre-condition has been 
updated according to the following rule: 

ackTime, ackuserid and ackSystemid are updated to contain no information; 
ackstate is updated to "unacknowledged". 


perceivedSeverityUp 
dated 


The perceivedSeverity attribute of matched Alarminf ormation identified in 
inv alarmMatched in pre-condition has been updated. 



Y.b.a.4 Constraints 

The < constraints> subclause presents constraints for the notification or its parameters. 

NOTE: This subclause does not need to be present when there are no constraints to define. 

Y.c Scenario 

This subclause contains one or more sequence diagrams, each describing a possible scenario. These shall be UML 
compliant sequence diagrams. This is an optional subclause. 
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